Error: Last_SQL_Errno: 1594 Last_SQL_Error: Relay log read failure: Could not parse relay log event entry.

This error message means that the copy of the MySQL replication log could not be read on the slave server. A common cause of this is where a slave server has not been cleanly rebooted. In some cases it may mean that the replication log contains errors on the master server, but this is less common.

** If you have MASTER-MASTER replication with additional SLAVE servers read through the notes at the bottom before continuing.

First run "show slave status \G" on the slave and note:

First we want to make sure that the master log file is intact, so jump onto the master server and find the Relay_Master_Log_File (check /var/log/mysql) and run the following command:

The log will be displayed but hopefully you won't see any error messages. If you see error messages then the master logs are corrupt and you'll likely have to re-image - stop following this answer now.

Next run the same command on the slave relay log (often in /var/lib/mysql)

You will likely see some errors showing the corruption that has stopped replication, like this:

If you see any errors then the log is fine on the master and only the slave's relay log is corrupt. This is good news, we can reset the slave and tell it the masters details and where to continue from. If you don't see any errors then stop reading now, you have a different problem.

If the slave relay log has errors, run the following commands to reset the slave and corrupted logs reconnect to the master, get the ok logs and start slaving again. Note that MASTER_LOG_POS is the Exec_Master_Log_Pos, and MASTER_LOG_FILE is the Relay_Master_Log_File both from the first command.

The reset slave command clears the slave's local copy of the master logs and some configuration. The "CHANGE MASTER" command reconfigures the replication. When the slave is started it gets new logs from the master server and starts replicating again.

Your replication should now be fixed and your master servers in sync.

MASTER-MASTER-SLAVE Information:

Please note the following if you are using MASTER-MASTER with additional SLAVE servers (ie you are replicating data from the 2 Master servers to additional MySQL instances):

Setup example:

If you have master servers MASTER1 and MASTER2, with an additional slave server SLAVE1 replicating from MASTER2, and you have had to stop, reset and restart replication on MASTER2, the slave server SLAVE1 may now try and process records from the log file from MASTER1 that it has already processed.

This may happen if the slave server had processed records from the log files from MASTER1 before they were cleared and re-downloaded on MASTER2. Depending on replication latency and data volumes this may only be a few log entries, but only you know your data or the impact this may have on integrity.

If this happens you will likely see the slave servers stop replicating due to DUPLICATE KEY errors when they insert something they've already received.

You can either recreate the slave servers to ensure you have valid data integrity, or skip the errors caused by reprocessing updates until it starts processing new log entries. You could also have a look in the MySQL log files to see what updates it contains.

If you want to skip past the errors as the slave server processes the log to get new data you can run the following command on the slave:

In a recent case we had to skip past 10 duplicate entry errors on a slave server before it got to new data. After skipping the 10th duplicate key error the slave continued working and was in sync with both master servers.

If I were using a SLAVE server for backups I would consider that it's data integrity was critical and re-image from a master. Otherwise you can make a judgement based on the servers application as to whether skip the errors or run checks on the data.